Object Interconnections C + + Servant Managers for the Portable Object Adapter ( Column 14 )

Welcome to the final installment of our series covering the new CORBA Portable Object Adapter (POA) specification. The POA allows servers to (1) generate and interpret object references, (2) activate and deactivate servants, (3) demultiplex requests to map object references onto their corresponding servants, and (4) collaborate with the automaticallygenerated IDL skeletons to invoke operations on servants. The POA is a component of CORBA visible solely to a server, i.e., clients are not directly aware of the POA’s existence or structure. The first column in this series [1] discussed the concepts and terminology used in the POA specification. It described how the lifetime of a CORBA object can be decoupled from the lifetime of any C++ servant(s) that implement it. The second column [2] expanded this discussion by exploring the two lifespans that are possible for CORBA objects: transient and persistent. These lifespans differ entirely by how long a CORBA object “lives.” Lifespan issues often arise when discussing object adapters since that’s where the worlds of CORBA objects and programming language servants intersect. Our third column [3] of the series described how to create C++ servants and register them in order to incarnate CORBA objects. For some applications, explicitly registering a servant for each CORBA object is prohibitively expensive; for others, it is virtually impossible. For instance, some applications contain many thousands of objects, with the state of each object kept separately in persistent storage. In such cases, it can be costly, in terms of memory resources, persistent storage access, and execution time, to create and register a servant for each CORBA object. There are also other types of applications that serve as gateways to other distributed systems, such as DCOM. When a new object is added to the DCOM system, the gateway needs to provide access to it dynamically, without needing to be shut down, recompiled, and restarted. Both types of applications described above must activate objects on demand as requests are actually made on them, rather than activating them all before the ORB starts listening for requests. The POA specification provides several mechanisms, i.e., servant managers and default servants, that allow applications with many objects to scale gracefully. Servant managers are responsible for managing the association of an object (as characterized by its Object Id value) with a particular servant, and for determining whether an object exists or not. Default servants can process requests for an object if no other servant is available for it. In this column, we first describe servant managers and then we explain default servants. As always, we provide C++ examples that show the details of how each is used.